How to deal with malleability of BitCoin transactions

BitCoin transactions are malleable in a sense that given a transaction an adversary can easily construct an equivalent transaction which has a different hash. This can pose a serious problem in some BitCoin distributed contracts in which changing a transaction’s hash may result in the protocol disruption and a financial loss. The problem mostly concerns protocols, which use a ”refund” transaction to withdraw a deposit in a case of the protocol interruption. In this short note, we show a general technique for creating malleability-resilient “refund” transactions, which does not require any modification of the BitCoin protocol. Applying our technique to our previous paper “Fair Two-Party Computations via the BitCoin Deposits” (Cryptology ePrint Archive, 2013) allows to achieve fairness in any Two-Party Computation using the BitCoin protocol in its current version. 1 Malleability of BitCoin transactions We assume that the reader is familiar with the BitCoin protocol and in particular with non-standard transaction scripts (used e.g. in so-called distributed contracts). For general description of BitCoin, see e.g. [4,1] or BitCoin wiki page http://en.bitcoin.it/. For the description of non-standard transaction scripts, see [2,1] or Contracts page http://en.bitcoin.it/wiki/Contracts. BitCoin transactions are malleable1 in a sense that given a transaction T it is easy to create a functionally identical transaction T ′ (T and T ′ differs only in the input scripts) which has a different hash2. This gives an adversary an opportunity to slightly change the transaction sent by a user before it is included in the blockchain. It strongly affects the distributed contracts which use the hashes of the transactions before broadcasting them. The source of the malleability is the fact that in the current version of the BitCoin protocol, each transaction contains a hash of the whole transaction it spends, while the signatures are taken over the simplified version of the transaction (excluding the input scripts). The most common scenario in which the malleability of transactions is a problem is the following. Suppose that there is a transaction Deposit , which should be redeemed by a transaction Fuse3 with time-lock t, but for some reason Fuse has to be created and signed before Deposit is broadcast.4. In the above scenario a problem arises if the Deposit transaction is maliciously changed and its version included in the blockchain has a different hash than expected, what invalidates the transaction Fuse. In our recent paper [1] we proposed a modification of BitCoin which eliminates the malleability problem. The idea of this modification was to identify the transactions by the hashes of their simplified versions (excluding the input scripts). With this modification one can of course still modify the input script of the transaction, but the modified transaction would have the same hash. We used this improvement of BitCoin to guarantee the correctness of the Fuse transactions, which had to be sign before broadcasting its input transaction. In this short note we present another approach to achieving the correctness of Fuse transactions which does not need any modification of the BitCoin protocol. ⋆ [email protected] ⋆⋆ [email protected] ⋆ ⋆ ⋆ [email protected] † [email protected] 1 See http://en.bitcoin.it/wiki/Transaction_Malleability. 2 This can be done e.g. by adding push and pop commands to the input script 3 Transactions of this kind are sometimes called refund transactions. 4 See e.g. examples 1, 5 and 7 on http://en.bitcoin.it/wiki/Contracts.